Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9608/000018_owner-urn-ietf _Fri Aug 16 17:55:35 1996.msg

Internet Message Format | 1997-02-19 | 4KB

Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id RAA21158 for urn-ietf-out; Fri, 16 Aug 1996 17:55:35 -0400
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id RAA21153 for <[e-mail]>; Fri, 16 Aug 1996 17:55:33 -0400
Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA27505  (mail destined for [e-mail]); Fri, 16 Aug 96 17:55:31 -0400
Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id PAA27469; Fri, 16 Aug 1996 15:55:28 -0600 (MDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 16 Aug 1996 16:00:43 -0600
To: [e-mail] (Daniel LaLiberte)
From: Ron Daniel <[e-mail]>
Subject: Re: [URN] revision of NAPTR draft
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
Reply-To: Ron Daniel <[e-mail]>
Errors-To: [e-mail]

Thus spoke Daniel LaLiberte (at least at 03:26 PM 8/16/96 CDT)

[Stuff on inability of regexps to revese order of components
 in an arbitrary length list deleted]

>In previous discussion with Ron, he suggested that it might be
>possible to use the resolution algorithm, as is but iteratively, to
>bite off a component at a time and construct the reversed DNS name.
>This sounds similar to what we recommend for the path scheme
>resolution in the first place, so I would be happy to go with it - it
>wouldnt require a list reversal extension.  But I don't see how it can
>be done.  Could you give an example of how this works?

Sure. Lets look at a semi-hypothetical name like
  janet:uk.ac.cam.eng:techrep-96-23

First, we extract the namespace identifier, janet, and
lookup(NAPTR, janet.urn.net) => a regexp like
  "s/(urn:)?janet:(.[^\.])*\.*/\2/i"
which matches everything after "janet:" but before the next "."

Now we lookup(NAPTR, "uk") => a regexp like
  "s/(urn:)?janet:uk\.(.[\.])*\..*/\2.uk/"
which matches everything after "janet.uk." but before the next ".".

Now we lookup(NAPTR, "uk.ac") => a regexp like
  "s/(urn:)?janet:uk\.ac\.(.[^\.])*\..*/\2.ac.uk/"

lookup(NAPTR, cam.ac.uk) =>
  "s/(urn:)?janet:uk\.ac\.cam\.(.[^\.])*\..*/\2.cam.ac.uk/"

lookup(NAPTR, eng.cam.ac.uk) =>
  terminal naptr telling us to fetch the SRV record for
  something like _ftp._tcp.eng.cam.ac.uk, with the SRV
  and A records included as additional info.

We pick one of those servers and ask it about techrep-96-23.


So, that is one way it could be done. I am not wild about the
number of lookups that are needed, but I like it better than
adding a non-standard flag to regexps.

I think it is pretty rare that we will have a namespace that
has such a mapping to DNS. For instance, an OID namespace
has its most significant components at the front of the name.
However, there is no good way to map 1.3.6.1.4.1.2 to ibm.com
and map 1.3.6.1.4.1.13 to utk.edu.  I think most namespaces
will very quickly point the user to a database that handles
very large chunks of the namespace. This is certainly how
names from schemes such as ISAN - Intl. Standard Audio-visual
Number - would work.

Handles are a namespace that comes close to this, but the mapping
between handle naming authorities and domain names is far from
exact, and we are likely to get instantly directed to G or to
a local handle server whenever we encounter a name in the hdl:
system.

Well, that's enough for a Friday afternoon.
Regards,

Ron Daniel Jr.                       email: [e-mail]
Advanced Computing Lab               voice: [phone]
MS B287                                fax: [phone]
Los Alamos National Laboratory        http://www.acl.lanl.gov/~rdaniel/
Los Alamos, NM, USA  87545       tautology:"Conformity is very popular"